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(54) IMethod and apparatus for transmitting operation packets between functional modules of a 
processor 

(57) An Integrated circuit comprising a plurality of 
functional modules and Interconnected via a pacl<et 
router for conveying request and response packets is 
described. Transactions involve the dispatch of request 
packets and receipt of corresponding response packets. 
Each packet conveys a number of transaction attributes 
which can control how the packet is managed by control 
circuitry which controls the flow of packets on the packet 
router For example the transaction attributes can 
include a transaction number, a grouping indicator, a 
priority indicator and a post indicator. 
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Description 

[0001] The present invention relates to the trans- 
mission of packets which contain transaction attributes. 
The invention is particularly but not exclusively con- 5 
cerned with the transmission of packets in an integrated 
circuit comprising a plurality of functional modules inter- 
connected via a packet router. 

[0002] Computer systems and integrated circuit 
processors exist which implement transactions with the io 
dispatch and receipt of packets. Request packets define 
an operation to be performed and response packets 
indicate that a request has been received and whether 
or not the operation defined in a request packet has 
been successfully candied out. The integrated circuit is 
processor can comprise a plurality of functional mod- 
ules connected to a packet router for transmitting and 
receiving the request and response packets. Transac- 
tions involve the dispatch of request packets and receipt 
of corresponding response packets. Each request 20 
packet prompts the generation of an associated 
response packet which is returned to the indicator of the 
request 

[0003] Cun-ent routing systems rely on an arbitra- 
tion mechanism which controls the flow of request and 25 
response packets over a packet router. This mechanism 
normally operates under the control of dedicated control 
signals from the functional modules, for example a 
request signal to request access to the packet router 
and a grant signal to grant access to the packet router. 30 
By increasing the number of dedicated control signals it 
is possible to increase the complexity of arbitration 
mechanisms, for example to take into account priority. 
Generally, the design process is such that the architec- 
ture of a processor is designed and the functional mod- 35 
ules which are required are determined. Then, 
depending on the nature of the functional modules and 
the requirements which their nature impose on the 
packet router, a suitable arbitration mechanism is imple- 
mented with the necessary packet protocol and control 40 
signals to support that mechanism. 
[0004] Generally, the control signals which control 
the arbitration apply globally across the packet router 
and are generated by the functional modules' internal 
routing circuitry. 

[0005] It is an aim of the present invention to pro- 
vide a packet protocol which can be utilised across a 
number of different projects and designs, and in partic- 
ular to allow for performance enhancements baised on 
transaction information. so 
[0006] According to one aspect of the present 
invention there is provided an integrated circuit compris- 
ing: a plurality of functional modules interconnected via 
a packet router, each functional module having packet 
handling circuitry for generating and receiving packets ss 
conveyed by the packet router; wherein a first set of said 
functional modules act as initiator modules and have 
packet handling circuitry which includes request packet 



generation circuitry for generating request packets for 
implementing transactions, each request packet includ- 
ing a destination indicator identifying a destination of the 
packet and a transaction field holding a unique transac- 
tion number for each request picket and at least one 
transaction attribute, and wherein a second set of said 
functional modules act as target modules and each 
have packet handling circuitry which includes packet 
receiver logic for receiving said request packets and 
response packet generation logic for generating respec- 
tive response packets, each response packet having a 
copy of the transaction field transmitted with the respec- 
tive request packet; the integrated circuit further com- 
prising routing control circuitry which is operable to read 
said at least one transaction attribute and to control the 
manner in which packets are conveyed by the packet 
router responsive to said at least one transaction 
attribute. 

[0007] The unique transaction number uniquely 
identifies the transaction with which that request packet 
is associated. When such a request packet is received 
at a destination module, a response packet is generated 
which also identifies the unique transaction number. 
This allows responses and requests to be matched at 
the initiator module, for example to reorder received 
responses such that they are properly associated with 
their respective requests. 

[0008] Thus, according to the present invention 
transaction attributes are associated with particular 
packets rather than with the system control. Thus, any 
systems which implement a distributed/hierarchical 
routing and arbitration system can utilise tiiis infomia- 
tion where it is important for system performance, and 
ignore it at points in the system where It is not Because 
the transaction attributes are associated with the pack- 
ets, they are always available. 

[0009] Another aspect of the invention provides an 
initiator functional module for connection in an inte- 
grated circuit comprising: an interfoce for supplying and 
receiving packets to and from the functional module, 
said interface being connected to a port for connecting 
the functional module to a packet router; packet han- 
dling circuitry for handling said packets and including 
request packet generating logic which generates 
request packets for supply to the packet router via the 
interface, each request packet having a destination indi- 
cator identifying a destination of the packet and a trans- 
action field which comprises a unique transaction 
number for each request packet and at least one trans- 
action attribute for use by routing control of the Inte- 
grated circuit in routing the transaction over the packet 
router. 

[0010] A further aspect of the invention provides a 
target functional module for connection in an integrated 
circuit comprising: an interface for supplying and receiv- 
ing packets to and from the functional module, said 
interface being connected to a port for connecting a 
functional module to a packet router; packet receiver 
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logic which is operable to receive request packets sup- 
plied from the packet router via the interface to the tar- 
get functional nnodule, each request packet having a 
transaction field including a unique transaction number 
and at least one transaction attribute, wherein the target 
module further comprises packet receiver logic for gen- 
erating respective response packets on receipt of each 
request packet, each response packet having a transac- 
tion field which holds a copy of the unique transaction 
number and said at least one transaction attribute con- 
veyed by the respective request packet. 
[0011 J A further aspect of the invention provides a 
method of implementing transactions in an integrated 
circuit comprising a plurality of functional modules Inter- 
connected via a packet router, the method comprising: 
at one of said functional modules acting as an initiator 
module, generating a request packet including a desti- 
nation indicator identifying a destination of the packet 
and a transaction field holding a unique transaction 
number and at least one transaction attribute associ- 
ated with the transaction; reading the transaction 
attribute conveyed by the request packet and using the 
transaction attribute in an arbitration mechanism con- 
trolling the flow of packets on the packet router; at the 
destination indicated by the destination indicator, 
receiving said request packet and generating a 
response packet for transmission to the initiator func- 
tional module, said response packet holding a copy of 
the transaction field of the corresponding request 
packet. 

[0012] A further aspect of the Invention provides a 
method of implementing transactions in an integrated 
circuit comprising a plurality of functional modules Inter- 
connected via a packet router, the method comprising: 
at one of said functional modules acting as an initiator 
module, generating a request packet including a desti- 
nation Indicator identifying a destination of the packet 
and a transaction field holding a unique transaction 
number and a post Indicator; detecting the post indica- 
tor at a local routing control unit and generating a 
response packet; at the destination indteated by the 
destination indicator, receiving said request packet and 
generating a further response packet with the post indi- 
cator set; and detecting receipt of the response packet 
at the local routing control unit and deleting said packet 
[0013] The transaction field can hold one or a plu- 
rality of transaction attributes. 

[0014] A first transaction attribute acts as a group- 
ing indfcator to indicate to the routing control circuitry 
that the performance of the system would be enhanced 
if the packets with this indteator set are kept in an unin- 
terrupted sequence. 

[0015] Because the transaction field is copied over 
to respective response packets, the same transaction 
attribute Is set in response packets of the linked or 
grouped memory access operations. This has a similar 
effect on the routing control circuitry. 
(001 6] Another transaction attribute acts as a prior- 



ity indicator to Indicate the priority of the transaction. 
The priority indicator can be used at the routing control 
circuitry to arbitrate transactions on the packet router. 
[0017] Another transaction attribute acts as a post 

5 bit whfch, when set in a request packet, causes the rout- 
ing control circuitry to generate a local response packet. 
When the request packet is received by the destination 
target module, a normal response packet with a copy of 
the transaction field is generated and in this case the 

10 routing control circuitry is operable responsive to setting 
of the post bit in the response packet to locally delete 
that response packet. 

[0018] For a better understanding of the present 
invention and to show how the same may be carried into 
15 effect reference will now be made by way of example to 
the accompanying drawings. 



Rgure 1 is a block diagram of a processor embod- 
ied as an integrated circuit with an external mem- 
ory; 

Figure 1 A is a block diagram illustrating initiator and 
target modules; 

Rgure 2 shows the packet handling logic; 
Rgures 3 and 4 are packet formats of request and 
response packets respectively conveyed by the 
packet router; 

Rgure 5 is a block diagram more cleariy illustrating 
the routing control signals; 

Rgure 6 illustrates a primitive memory access oper- 
ation; 

Rgure 7 illustrates a compound memory access 
operation; 

Rgure 8 illustrates the construction of the transac- 
tion field; and 

Rgure 9 is a block diagram illustrating the interface 
signals of functional modules. 
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[0019] Rgure 1 Illustrates an integrated circuit 
according to an embodiment of the invention. On each 
40 chip 1 1 a CPU unit 1 2 Is connected to a plurality of mod- 
ules M by a data and address path 15 arranged to carry 
bit packets In parallel form. The modules as well as the 
CPU unit 12 each include packet handling circuitry 2 
used in the generation and receipt of bit packets on the 
45 path 15. The path 15 is referred to herein as a packet 
router or routing bus. Two main types of packet are used 
on the data and address path 15, each including a des- 
tination indicator or address to Indicate the required 
destination module connected to the path 15. The pack- 
50 ets include request packets which are generated by an 
initiator module and response packets whteh are gener- 
ated by a target module. A module may act as both an 
initiator and a target. Response packets are of two 
types, ordinary responses or error responses. These 
55 are discussed in more detail later. The modules M as 
well as the CPU unit 12 each have packet handling cir- 
cuitry 2 for handling packet formation and receipt of 
requests, ordinary responses and error responses. 



3 



5 



EP 1 091 301 A2 



6 



[0020] The routing bus 15 provides bi-directional 
connections to each module. In this example the bus 
consists of parallel request and response buses and a 
dedicated control bus provided respectively for each 
module so as to link the modules to an arbitration unit 
22. Each module is connected to the routing bus via a 
port 4 and is provided with an interface 6 incorporating 
a state machine so as to interchange control signals 
and data between the port 4 and the interface 6. 
[0021 1 Rgure 1 A is a block diagram illustrating rele- 
vant functional components of the chip of Figure 1 to 
illustrate the concept of targets and initiator modules. 
The modules are labelled Ml , M2, M3 and M4 and may 
include any of the modules M already described with 
reference to Rgure 1. Modules Ml and M2 both have 
target and initiator functions as illustrated by the sepa- 
rate target and initiator parts of the interface 6 of each 
module. Module M3 acts only as an Initiator and module 
M4 acts only as a target. Signals from the interfaces 6 
are supplied to central control logic which forms part of 
the arbitration unit 22. The arbitration unit 22 issues 
request routing controls and response routing controls 
to the routing bus network 15. 

[0022] In the example shown in Rgure 1 , the vari- 
ous modules 14 include a debug module 30 which 
includes an external link 31 for transmitting packets 
across the chip boundary, an external memory interface 
EMI 32 having an external bus connection 33 leading to 
an external memory 50, clock circuitry 34, various 
peripheral interfaces 35, a peripheral component inter- 
face PCI 37 with an external: connection 38, a DMA unit 
25 for effecting memory accesses as well as the art^itra- 
tion unit 22. The CPU unit 12 includes a plurality of 
instruction execution units 40, a plurality of registers 41 , 
and a cache 42. The CPU unit 12 also includes packet 
handling circuitry 2 connected to the execution units 40. 
The routing bus 15 is arranged to transmit to the mod- 
ules M both request and response packets for effecting 
memory access transactions as discussed further 
herein. These packets may be generated by software as 
a result of instruction execution by a CPU or by hard- 
ware responsive to detection of a packet. Initiator mod- 
ules can act autonomously to generate packets. The 
packets may be generated on-chip and distributed on 
the bus 15 or generated off-chip and supplied to the on- 
chip bus 15 through an external connection such as the 
link 31 associated with the debug module 30. 
[0023] The CPU can be operated in a conventional 
manner receiving instructions from a program memory 
and effecting data read or write operations with the 
cache 42 on-chip. Additionally external memory 
accesses for read or write operations may be made 
through the external memory interface 32 and bus con- 
nection 33 to the external memory 50. 
[0024] The debug module 30 provides an important 
external communication whteh may be used for example 
in debugging procedures. The on-chip CPU 12 may 
obtain instruction code (by memory access packets) for 



execution from an external source such as a debugging 
host 60 communicating through the link 31. Communi- 
cations on the routing bus 15 are carried out in bit paral- 
lel format It is possible to reduce the parallelism of 
5 packets obtained from the routing bus 15 so that they 
are output in bit serial format through the link 31 . 
[0025] Each packet is constructed from one or more 
cell or token, the end of the packet being identified by an 
end of packet (eop) signal. The construction of the cells 
10 is discussed in more detail later. Briefly, each packet cell 
comprises a number of fields which characterise the 
packet. Each packet is transmitted by a source module 
and is directed to a destination module. An initiator can 
issue request packets and act on response packets. A 
15 target can receive and act on requests and issue 
responses. Thus, a source module may be an initiator or 
a target depending on the nature of the packet. The 
source module uses its associated port 4 to transmit a 
packet onto the routing bus 15. The routing bus 15 
20 arranges for the packet to be routed to the port associ- 
ated with the destination module. The destination mod- 
ule then receives that packet from its associated port. 
The source and destination modules can be the same. 
[0026] A transaction is an exchange of packets that 
25 allows a module to access the state of another module. 
A transaction consists of the transfer of a request packet 
from a source module to a destination module, followed 
by the transfer of a response packet from that destina- 
tion module (now acting as a responding module) back 
30 to the source module which made the original request. 
The request packet initiates a transaction and its con- 
tents detemnine the access to be made. The response 
packet completes the transaction and its contents indi- 
cate the result of the access. A response packet also 
35 indicates whether the request was valid or not If the 
request was valid, a so-called ordinary response packet 
is sent. If the request was Invalid, an en-or response 
packet is transmitted. Some modules act only as initia- 
tors and thus their packet handling circuitry 2 is capable 
40 only of the generation of request packets. Some mod- 
ules act only as targets, and therefore their packet han- 
dling circuitry 2 is capable only of generating response 
packets. In that case, both ordinary responses and error 
responses can be generated. However, some modules 
45 are capable of acting both as initiators or as targets, and 
their packet handling circuitry is capable of generating 
both request and response type packets. A logic dia- 
gram for the relevant parts of a module capable of both 
these functions is shown in Rgure 2. The packet han- 
50 dler 2 comprises request generator logic 200, ordinary 
response generator logic 202, error response generator 
logfc 204, request packet receiver logic 206, and 
response packet receiver logic 208. These are all under 
the general functional control of a control logto block 
55 210. A request packet is constructed by a requesting 
module when that module needs to make an access to 
a partteular target module. As discussed more fully 
later, the address of the target module is recorded in the 
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request packet destination flelcl. The requesting module 
acts as a source of the request packet and sends that 
packet into the routing bus 15. The routing bus 15 
arranges for that request packet to be routed from its 
source to its destination. The destination receives the 
request packet from the routing bus 15. The request 
packet receiver logk; 206 checks whether or not the 
request is valid at 206a. If it is valid, an ordinary 
response packet is generated by the ordinary response 
generator logic 202 and the module services the 
requested access according to the information in the 
received request packet. If the request is not valid, the 
error response generator logic 204 generates an error 
response packet. 

[0027] A response packet (ordinary or en-or) is con- 
structed In order to reply to the request packet. The 
module which originated the request packet is recorded 
in the response packet's destination field. The respond- 
ing module is the source of the response packet and 
sends that packet onto the routing bus 15. This is done 
by the module interface 6. The response receiver logic 
208 receives the response packet from the routing bus 
15 and checks the response at 208a. If the response 
can be matched to the original request, the transaction 
is completed. 

[0028] The fomiat of the multibit packets used on 
the routing bus 15 in the microcomputer are illustrated 
by way of example in Figures 3 and 4. Figure 3 shows 
the information carried by each request cell. 
[0029] Each packet is constructed from a series of 
cells framed using an end of packet (eop) signal. Each 
request cell comprises a 32-bit address field which indi- 
cates the destination address of the packet. In the 
described embodiment, an address comprises an 8-bft 
destination field 73 followed by a 24-bit offset field 63 
which identifies a memory location within the destina- 
tion. The offset information is present in request packets 
to identify the particular memory location at which the 
request is targeted. The destination field 73 is a 1-byte 
field used to route the packet to the destination or target 
module. A byte 74 conveys the opcode which identifies 
the nature of the requested access. For example, the 
opcode can define a load word access for reading a reg- 
ister value and a store word access for writing a register 
value. A SRC byte 99 is a source field which identifies 
the source module and which is used as a return 
address for a response packet A transaction field byte 
98 conveys a unique transaction number whfch is used 
by the requester to associate responses with requests. 
The transaction number enables a module to identify i 
response packets corresponding to respective request 
packets in cases where a plurality of request packets 
have been sent before response packets have been 
received for each request packet. As discussed in more 
detail later, the transaction field also holds transaction s 
attributes describing the transaction to the system. A 
64-bit data field 71 holds data to be conveyed with the 
request. 



[0030] Rgure 4 illustrates the construction of a 
response packet cell. If the response packet contains 
more information than a single cell, it is constructed 
from a sequence of cells framed using a response end 
5 of packet (r_eop) signal. The response packet includes 
an opcode byte 85 which denotes the nature of the 
requested transaction, a byte 84 whfch identifies the 
source module of the requesting packet whteh gave rise 
to the response and which acts as the return address for 
10 the response packet, a transaction field byte 98 and a 
data field 69. The transaction field byte of a response 
packet holds a copy of the transaction field byte 98 of 
the corresponding request packet. 
[0031] The opcode field 74 of a request packet has 
15 a number of different possible encodings to define the 
nature of the requested access. Bit 7 of the opcode is 
used to identify whether it is a request or a response 
packet however. With bit 7 set to one, the packet is a 
response and which bit 7 set to zero, the packet is a 
20 request. The opcode field 85 of the response packet 
thus has bit 7 set to one in each case. In addition, bit 0 
is set to zero if the response is a ordinary response 
(successful transaction), and is set to one if it is an en-or 
response. Thus, the opcode field can quickly and readily 
25 identify whether a packet is a request or a response and 
whether the response is an ordinary response or an 
error response. 

[0032] The function of the arbitration unit is to con- 
trol packet flow on the packet router. In the described 

3o embodiment, the system guarantees to start all opera- 
tions from a single source to a single memory location In 
the same order, to route all responses from a single 
source back to the same initiator and. In an order sys- 
tem, to return all responses back to a single source in 

35 the same order as requests were issued. The basic 
function of the arbitration unit follows below. It will read- 
ily be appreciated however that any suitable arbitration 
mechanism can be utilised with the transaction 
attributes discussed herein. 

40 [0033] When a module has a packet to send to 
another module, for example from the CPU unit 12 to 
the EMI module 32. it first signals this by asserting a 
request signal req to a dedicated line connecting that 
module to the central art>itration unit 22. Reference is 

ts made to Figure 5 where Ml Is the initiator module and 
M2 the target module. It also outputs an eight bit signal 
to indk:ate to the ari3itratlon unit 22 the intended desti- 
nation of the packet it wishes to transmit A module M 
which is able to receive a packet from the routing bus 15 

io will assert a grant signal gnt to the central arbitration 
unit 22 regardless of whether a packet is available to be 
fed to that destination or not When the central arbitra- 
tion unit 22 determines that a module wishes to send a 
packet to a destination and independently the destina- 

5 tion has indicated that it is able to receive a packet from 
the bus 15, the unit 22 arranges for the transfer to take 
place. The unit 22 asserts a 'grant send" signal gnt_snd 
to the appropriate interface 6 causing the sending mod- 
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ule to put the packet onto the bus 1 5. The arbitration unit 
22 then asserts a "send" signal snd which signals to the 
receiving module that it should accept the transfers cur- 
rently on the bus 16. The packet transmission con- 
cludes when the sender asserts an "end of packet* 
signal concurrently with the last transfer of packet data 
on the bus 15. 

[0034] Although this description is made with refer- 
ence to request packets, a similar arbitration mecha- 
nism applies for response packets. Figure 5 also 
illustrates signals derived from the transaction attributes 
which are used in routing control and arbitration. These 
are discussed later. 

[0035] In order to better understand the functions of 
the indicators to be described in the following which are 
held in the transaction field 98. reference is made to Fig- 
ure 6 to describe a complete transaction. In Figure 6, IM 
denotes an initiator module, TM denote a target module 
and PR denotes the packet router or routing bus 1 5. 
[0036] A transaction is initiated by fomning a 
request packet at the initiator module. The request 
packet is placed onto the packet router 15 by the initia- 
tor port associated with the initiator module IM and is 
conveyed by the packet router 15 to the target module 
defined in the destination field of the request packet. 
The memory access operation requested in the request 
packet is implemented and a response packet is formu- 
lated by the target module, placed on the packet router 
via the port associated with the target module and 
returned to the initiator module. Only then is a transac- 
tion deemed to be completed. Figure 6 illustrates a so- 
called primitive transaction made up of a single request 
and response. Each request packet canies a unique 
transaction indteator which identifies that transaction by 
a number generated by the initiator module. This will be 
termed herein the transaction number. When the 
response packet is formulated at the target module TM, 
it contains the same transaction number as that con- 
veyed by the request packet. Thus, when the response 
packet is received at the initiator module, the transac- 
tion number conveyed by the response can be matched 
to the transaction number of the initial request to con- 
finn that the transaction has been completed. Each 
request packet generated by a particular initiator mod- 
ule has a unique transaction number. 
[0037] The system described herein also supports 
so-called compound transactions. A compound transac- 
tion involves multiple request/response packets from a 
single module. This is illustrated diagrammatically in 
Figure 7. It is assumed for the purposes of the example 
of Figure 7 that this particular compound transaction 
involves the issuance of three request packet REQ1, 
REQ2, REQ3 by the initiator module. These request 
packets are transmitted via the packet router 15 to the 
target module. By using the lock signal described later, 
the arbitration module 22 controls the packet flow 
across the packet router to ensure that all three request 
packets are conveyed from the initiator module to the 



target module without interruption. As each request 
packet reaches the target module, a respective 
response packet REP.1. REP2, REP3 is generated and 
conveyed by the packet router 1 5 to the initiator module. 
5 Each of the request packets REQ1 , REQ2. REQ3 in the 
same compound transaction shares the same transac- 
tion number which is returned in the associated 
response packets. The fact that the transaction is a 
compound transaction can be conveyed in the opcode 
10 of the request packets. In this case, the arbitration unit 
22 is caused to ensure that the initiator module remains 
locked until the complete compound transaction has 
been finished. 

[0038] Another form of transaction is a so-called 
15 linked or grouped transaction. In this case, a TMI (trans- 
action message infomnation) bit in the transaction iden- 
tifier field Indicates that perfomiance of the system may 
be enhanced if packets in which this attribute is set are 
treated preferentially by the arbitration unit 22. For 
20 example, in the case of a round-robin arbiter which 
rotates after each access, it could indicate to the arbitra- 
tion unit that the next member packet in the linked group 
should be allowed access to the packet router. Thus, if 
the TMI bit is set to zero, this indicates that the transac- 
25 tion has no relationship with the next transaction (end of 
message) or, when the bit is set to one. it indicates that 
the next transaction Is related to this transaction (part of 
a message). The packet protocol described herein 
allows for the existence of this TMI bit which may be uti- 
30 lised by the arbitration unit 22 as described to enforce 
the grouping as the system perfomnance requirements 
demand it. However, if the system performance does 
not require it, the bit can simply be ignored without 
impacting the arbitration performance. 
35 [0039] A good example of use of the TMI bit is 
where a plurality of accesses are to be made to the 
same page in memory via the EMI interface 32. By link- 
ing these accesses, the EMI interface can more effi- 
ciently utilise its resources to access the page rather 
40 than treating each access as a new access. 

[0040] The TMI bit is included in both the request 
and response packets and therefore may be used to 
enhance the transaction perfonnance of one or both 
phases. 

45 [0041] Figure 8 is a diagram illustrating the bit 
encoding of the transaction identification field 98 illus- 
trated in Figures 3 and 4. Note that the same enhance- 
ments are available in both the request and response 
packets. It is the same in both request and response 
50 packets. A response packet contains a copy of the 
request packet transaction field. In addition to the four 
bit transaction number at bits 0 to 3 and the TMI bit at bit 
4, the transaction identifier field includes a priority bit 
PRI and a post bit POST. The function of these bits will 
55 be described later with reference to the routing control 
mechanism. 

[0042] Figure 9 illustrates the signals which are 
supplied between the interfaces of respective initiator 
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and target modules and their associated ports 4. In the 
diagram of Rgure 9, each line conveyed between the 
interface 6 and its respective port 4 is marked with a sig- 
nal name. These signal names are used in the following 
to denote the signals carried by appropriate wires, with- 5 
out reference numerals for the salce of clarity of the dia- 
gram of Figure 9. The same signal names are used in 
Rgure 5. Some of the signals are generated by control 
logic in the module, while other signals are generated 
from fields in the packets which are formed by the 10 
packet handling circuitry of each module. Thus, the initi- 
ator module includes control logic 210, request genera- 
tor logic 200 and response receiver logic 208. The 
target module also includes control logic 210 and fur- 
ther includes request receiver logic 206 and a response 75 
generator which is labelled 202,204. Thus, the ordinary 
response generator logic and the error response gener- 
ator logic illustrated in Rgure 2 have been combined 
into one block for the purposes of explanation of Rgure 

[0043] In the initiator module, the control logic 210 
generates request req and end of packet eop signals. 
The request generator logic formulates a request packet 
as described earlier whteh causes the following signals 
to be generated: ^ 

address, add 
opcode, opc 

mask, en (short for byte enable) 

data, 30 
transaction identifier, tid (including transaction 
number, post, TMI) 
source identifier, src 
lock. \ck and 

priority, pri. 35 

[0044] In addition, the initiator module receives the 
following signals. A response end of packet signal r_eop 
Is received by the control logic 210 as is the grant signal 
gnt The response receiver logic 208 receives the fol- 40 
lowing response packet signals r_opc, r_data, r_src, 
r_tid, r_pri and rjck. The grant signal gnt, the response 
end of packet signal r_eop are generated by the control 
block 210. The remaining signals are formulated from 
the packet which is generated by the response genera- 4s 
tor 

[0045] The function of these signals and how they 
are derived from the packet fields is discussed below. 

request (req) ready to send data 50 

This is driven by an initiator module IM and is 
used to indicate that rt is ready to transfer a request 
or element of a request across the interface. If this 
signal is asserted the request content and framing 
signals are valid. 55 

Initiators indbate they have data to send by 
asserting request and expect a grant in this or sub- 
sequent cycles to complete the transfer. 



grant (gnt) ready to accept data 

This is driven by a target module TM and is 
used by the target to indicate it is ready to accept 
data. A data or cell transfer across the interface 
occurs when the initiator is ready to send and the 
target is ready to accept, i.e. both request and grant 
are asserted at a rising clock edge. 

Targets indicate they are able to accept data by 
asserting grant and expect a request in this or sub- 
sequent cycles to complete the transfer. 

end of packet (eop) final cell of packet 

This driven by the Initiator and indicates this is 
the final cell of a request packet 

lock (Ick) transaction lock 

This indteates to the system that this transac- 
tion is made up or more than one request/response 
pairs. It acts as a general mechanism to link two or 
more request packets to make a linked compound 
operation. Depending on the implementation of the 
system the lock signal can be derived from the 
opcode. As illustrated in Rgure 5, the lock signal is 
supplied by the initiator to the arbitration unit 22. 

address (add) the transaction target address 

This is the address of the target module, and 
the location within the target module the operation 
will occur on. 

opcode (opc) the operation associated with the 
transaction 

This defines the transaction operation. It is not 
generally interpreted by the interconnect or trans- 
port medium. The opcode information remains con- 
stant across all request cells associated with the 
transaction. 

Compound operations may be built from multi- 
ple request/response packets linked via the lock 
mechanism. 

mask (en) defines the bytes within the cell on which 
the t£u^et should complete the operation 

mask<0) is associated with data(7:Q>, and so 
forth to the most significant byte. 

data defines the data being carried with the cell 

The data field is made up of a set of byte quan- 
tities, each byte being assodated uniquely with a 
specific mask bit Each byte is organised as a bit lit- 
tle endian quantity. The data field may contain mul- 
tiple bytes, these are organised in a byte significant 
manner. 

Data quantities larger than the natural bus 
width are always send using incrementing 
addresses, with the address wrapping at the 2" 
boundary associated with that data quantity. 



7 



13 

source (src) soutx^e identifier 

This identifies the source of the transactions to 
the systenn. It allows the system (and target mod- 
ules) to associate a series of transactions with a 
specific source of data. s 

identifier (tid) this includes the transaction number, 
post and TMI bits 

The transaction number allows each transac- 
tion to be uniquely labelled. The transaction 10 
numk>er of a request is used in the associated 
response. 

priority (pri) this defines the transaction priority 

This bit labels the transaction with an urgency is 
level which the system interconnect may use to 
implement preferential arbitration and/or overtalc- 
Ing. It is used only to implement system perform- 
ance enhancements. It is implemented in both the 
request paclcet and its associated response packet. 20 

response request (r_req) this Indicates a 
response cell is available 

An initiator should only commence a transfer if 
It is ready to accept the response packet. 2s 

response grant (r _^nt) this tndtoates a response 
cell may be accepted 

response lock (rjck) transaction lock 30 

This indicates to the system that this transac- 
tion is made up or more than one request/response 
pairs. It acts as a general mechanism to link two or 
more response packets to make a compound oper- 
ation. 35 

response opcode (r_opc) information about the 
response being presented to the initiator 

That is. whether the operation was successful 
(ordinary response) or an error arose (error 4o 
response). 

response data (r_data) this defines the data being 
carried with the response cell 

A response packet will contain as many 45 
response cells as it required to build a response 
packet to transfer the number of words required by 
the transaction. 

response source (r_src) a copy of the source iden- so 
tification field 

response identifier (r_tid) a copy of the transac- 
tion number 

These fields allow the response cell packet to 55 
be identified within a system enabling performance 
optimization and observability of transactions within 
the system. The encoding of these fields corre- 
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spends to that of the associated request fields. 

response priority (r_pri) this defines the transac- 
tion priority 

This field labels the response Information with 
an urgency level which the system interconnect 
may use to implement preferential arbitration. This 
is a copy of the priority bit of the request packet. 

[0046] It will be appreciated from the above that 
some of the signals generated across the routing bus 1 5 
by the initiator and target modules IM, TM are supplied 
to the arbitration unit 22 to implement control of packet 
flow on the bus 15. Other signals are supplied directly 
from the initiator module to the destination target mod- 
ule. They have no function in the routing control itself. 
[0047] In particular, the dest, request, grant, end of 
packet, lock and priority signals on both the request and 
response sides are utilised by the arisitratlon unit 22 to 
control packet flow. The remaining signals are not 
required for arbitration and are therefore routed directly 
from an initiator module to the destination target mod- 
ule. The transaction field 98 contains information of both 
kinds. The transaction number uniquely identifies a 
transaction to allow request and response packets to be 
matched at the initiator module. The transaction number 
is copied from a request packet to a response packet for 
this purpose. 

[0048] The TMI bit of a transaction field can be used 
to advise the arbitration unit that perfomnance will be 
improved if ail of the request packets in a linked group 
can be transmitted in unintenrupted fashion across the 
routing bus 1 5. The TMI bit in a request packet is copied 
into the respective response packet so that the 
responses can be similarly treated. 
[0049] The priority bit PRr likewise is derived from 
the transaction field and is used to control the priority 
with which the particular transaction is routed. Once 
again, the priority bit Is copied from the transaction field 
of the request packet into the transaction field of the 
response packet. 

[0050] The transaction field 98 also includes a post 
bit POST which is used by routing control which may be 
present in the arbitration unit 22 or elsewhere in the sys- 
tem to create a local response packet when a request 
packet having the post bit set is received. When the 
request packet reaches its final destination target mod- 
ule, the post bit is copied into the transaction field of the 
appropriate response packet and when this Is detected 
by the routing control the response packet is deleted 
because the routing control knows that a response 
packet has already been generated. 
[0051] For the sake of completeness, there follows 
the memory access operations supported by the sys- 
tem: 
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Load M Bytes 
Definition 
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RmodW lyi Bytes 
Definition 
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[0052] Transfer a single aligned word o( m bytes 
from the target to the initiator. 

[0053] Valid sizes for m are defined to be 2" were n 
is an integer in the range 0-6. 



Qualifiers 
[0054] 

address(31:n) 



the address of the word to be 
accessed 



address(n-1 :a> 



the address of the most critical byte 
within the word. This ensures the 
system will return the critical byte 
as part of the first cell in the 20 address(n-1:0} 
response packet. 



5 [0058] Transfer the value of the aligned word of m 
bytes from the target to the initiator, leaving the target 
device "locked" until a second transfer from the initiator 
to the target completes, replacing the infonmation held 
at that address in the target device. 

10 [0059] Valid sizes for m are defined to be 2" where 
n is an integer in the range 0-6. 



Qualifiers 
75 [0060] 

addressOl :n> 



mask(2^n-1:0) 



the mask indicates which bytes with 
the word are significant 



r_data(8x2"-1:0) data to be transferred, the signifi- 
cance of bytes within this field is 
inferred from the mask information 



result of operation 



r.opoode 
Store M Bytes 
Definition 



[0055] Transfer a single aligned word of m bytes 
from the initiator to the target, overwriting the tocation at 
that address with the data transferred. 
[0056] Valid sizes for m are defined to be 2" where 
n is an integer In the range 0-6. 



Qualifiers 
[0057] 

addressOl :n) 



25 



30 



35 



mask(2'^n-1:0> 
dataOx2"-1:0): 



the address of the word to be 
accessed 

the address of the most critical 
bytes within the word 

the mask indicates which bytes with 
the word are significant 

data to be transfen-ed from the Initi- 
ator to the target 



r_data<8x2"-1:0) data to be transfen-ed from the tar- 
get to the initiator 

Swap M 3yt^ 
Definition 



the address of the word to be 
accessed 



[0061] Exchange the value of the single aligned 
word of m bytes from the initiator with the data held in 
the target location, returning the original target data to 
the initiator. 

40 [0062] Valid sizes for m are defined to be 2" where 
n is an integer in the range 0-6. 

Qualifiers 

45 [0063] 

addressOl :n) 



addre88(n-1:Q> the address of the most critical byte 
within the word 

mask{2^n-1:0> the mask indicates which bytes with 
the word are significant 

dataOx2"-1 :0> data to be transfen-ed 



so addre88<n-1:0> 
mask(2''n-1:0) 



55 



data(8x2"-1:0) 



the address of the word to be 
accessed 

the address of the most critbal 
byte within the word 

the mask indicates which bytes 
with the word are significant 

data to be transferred from the ini- 
tiator to the target 
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r_clata(8x2"-1 :0>: data to be transferred from the tar- 
get to initiator 

Load a Gro up of words of M bvtes: Load QrouP 

Definition 

[0064] Transfer a group of single aligned words of m 
bytes fronn the target to the Initiator. 
[0065] The group consists of a number of elements, 
each of which contains m bytes, valid values for m are 
2" where n is an integer in the range 0-6. 

Qualifiers 



[0066] 

g*address<31:n): 
g*address<n-1:0} 
g*maslc(2'^n-1 :0> 



the address of the word to be 

accessed 

the address of the most critical 
byte within the word 

the mask indicates which bytes 
within each word are significant 



g*maslc<2^n-1:0) 
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the mask indicates which bytes 
with the word are significant 
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g*r_data(8x2"-1 :0> data to k>e transfenred, the signifi- 
cance of bytes within this field is 
inferred from the mask informa- 
tion 

[0067] The group contains g* m bytes of data, and 
is complete when eop is asserted on the final cell of the 
final word to be transferred. 

[0068] The operation is a mechanism for the initia- 
tor to force the system to maintain a series of possibly 
unrelated operations as a single element. 

Store a Group of Words of M Bvt es: Store Group 
Definition 

[0069] Transfer a group of single aligned words of 
size m bytes from the initiator to the target, overwriting 
the information at that address with the data transferred. 
[0070] The group consists of a number of elements, 
each of which contains m bytes, valid values for m are 
2" where n is an integer in the range 0-6. 

Qualifiers 

[0071] 

g*acidre8S(31:n> the address of the word to be 
accessed 

the address of the most critical 
byte within the word 



g*r_data(8x2"-1 :0) data to be transfenred 

[0072] The group contains g* m bytes of data, and 
is complete when eop is asserted on the final cell of the 
final word to be transfen-ed. 

[0073] This operation is a mechanism for the initia- 
tor to force the system to maintain a series of possibly 
unrelated operations as a single element. 

Claims 



15 1 . An integrated circuit comprising: 

a plurality of functional modules interconnected 
via a packet router, each functional module 
having packet handling circuitry for generating 
and receiving packets conveyed by the packet 
router; 

wherein a first set of said functional modules 
act as initiator modules and have packet han- 
dling circuitry which includes request packet 
generation circuitry for generating request 
packets for implementing transactions, each 
request packet including a destination indicator 
identifying a destination of the packet and a 
transaction field holding a unique transaction 
number for each request packet and at least 
one transaction attribute, and 
wherein a second set of said functional mod- 
ules act as target modules and each have 
packet handling circuitry which includes packet 
receiver logic for receiving said request pack- 
ets and response packet generation logic for 
generating respective response packets, each 
response packet having a copy of the transac- 
tion field transmitted with the respective 
request packet; 

the integrated circuit further comprising routing 
control circuitry which is operable to read said 
at least one transaction attribute and to control 
the manner in which packets are conveyed by 
the packet router responsive to said at least 
one transaction attribute. 



20 



25 



30 



35 



40 



45 



50 



g*address<n-1 :0) 



2. An integrated circuit according to claim 1 , wherein 
the transaction attribute 

3. An integrated circuit according to claim 1 , wherein 
said at least one transaction attribute indicates the 
priority of the transaction, the routing control cir- 
cuitry being operable to utilise this priority to arbi- 
trate transactions on the packet router. 

4. An integrated circuit according to claim 1 , wherein 
said at least one transaction attribute comprises a 
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post bit which, when set in a request packet 
causes the routing control circurtry to generate a 
local response packet. 

5- An integrated circuit according to claim 4, wherein s 
the routing control circurtry Is operable responsive 
to setting of the post bit in a response packet to 
locally delete that response packet. 

6. An integrated circuit according to claim 1 , wherein w 
the transaction field comprises a plurality of trans- 
action attributes. 

7. An integrated circuit according to claim 6. wherein 
said transaction attributes include a grouping indi- is 
cator, a priority indicator and a post indicator. 

8. An integrated circuit according to claim 6, wherein 
the packet includes an operation field denoting the 
function to be implemented by the request packet. 20 

9. An initiator functional module for connection in an 
integrated circuit comprising: 

an interfiace for supplying and receiving pack- 25 
ets to and from the functional module, said 
interface being connected to a port for connect- 
ing the functional module to a packet router; 
packet handling circuitry for handling said 
packets and including request packet generat- 30 
ing logic which generates request packets for 
supply to the packet router via the Interface, 
each request packet having a destination Indi- 
cator identifying a destination of the packet and 
a transaction field which comprises a unique 3S 
transaction number for each request packet 
and at least one transaction attribute for use by 
routing control of the integrated circuit in rout- 
ing the transaction over the packet router. 

40 

10. A target functional module for connection in an inte- 
grated circuit comprising: 

an interfiace for supplying and receiving pack- 
ets to and from the functional module, said 4S 
interface being connected to a port for connect- 
ing a functional module to a packet router; 
packet receiver logic which is operable to 
receive request packets supplied from the 
packet router via the interface to the target so 
functional module, each request packet having 
a transaction field including a unique transac- 
tion number and at least one transaction 
attribute, wherein the target module further 
comprises packet receiver logic for generating 55 
respective response packets on receipt of each 
request packet, each response packet having a 
transaction field which holds a copy of the 



unique transaction number and said at least 
one transaction attribute conveyed by the 
respective request packet. 

11. A method of implementing transactions in an inte- 
grated circuit comprising a plurality of functional 
modules interconnected via a packet router, the 
method comprising: 

at one of said functional modules acting as an 
initiator module, generating a request packet 
including a destination indicator identifying a 
destination of the packet and a transaction field 
holding a unique transaction number and at 
least one transaction attribute associated with 
the transaction; 

reading the transaction attribute conveyed by 
the request packet and using the transaction 
attribute in an arbitration mechanism control- 
ling the flow of packets on the packet router; 
at the destination indicated by the destination 
indicator, receiving said request packet and 
generating a response packet for transmission 
to the initiator functional module, said response 
packet holding a copy of the transaction field of 
the corresponding request packet. 

12. A method according to claim 11, wherein said at 
least one transaction attribute indicates the priority 
of the transaction. 

13. A method of implementing transactions in an inte- 
grated circuit comprising a plurality of functional 
modules interconnected via a packet router, the 
method comprising: 

at one of said functional modules acting as an 
initiator module, generating a request packet 
including a destination indicator identifying a 
destination of the packet and a transaction field 
holding a unique transaction number and a 
post Indicator; 

detecting the post indicator at a local routing 
control unit and generating a response packet; 
at the destination indteated by the destination 
indicator, receiving said request packet and 
generating a further response packet with the 
post indicator set; and 

detecting receipt of the response packet at the 
local routing control unit and deleting saki 
packet 
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□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 
^REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 
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